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Abstract — Network simulator software tools are often used to 
model the behaviors and interactions of applications, protocols, 
packets, and data links in terrestrial communication networks. 
Other software tools that model the physics, orbital dynamics, 
and RF characteristics of space systems have matured to allow 
for rapid, detailed analysis of space communication links. 
However, the absence of a unified toolset that integrates the two 
modeling approaches has encumbered the systems engineers 
tasked with the design, architecture, and analysis of complex 
space communication networks and systems. This paper presents 
the unified approach and describes the motivation, challenges, 
and our solution - the customization of the network simulator to 
integrate with astronautical analysis software tools for high- 
fidelity end-to-end simulation. 
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I. Introduction 

The motive for developing a unified approach to the 
modeling and simulation of space communication networks is 
twofold. First, there is an increased need for internetworking in 
space ever since missions started using Internet Protocol (IP) 
endpoints onboard space assets in the 1990s. In the near future, 
the need for a robust network of networks becomes essential 
for NASA's proposed lunar, Martian, and deep space 
exploration missions. The communications architectures 
proposed for these missions are more complex than any prior, 
so there is a need for thorough, end-to-end simulation during 
the formulation phases [1] [2] [3]. 

Furthermore, such higher-fidelity system simulations 
require an integration of existing capabilities from the subject 
matter expert domains of networking, satellite 
communications, and mission planning. Discrete-time, event- 
based network simulators are often used for terrestrial network 
projects, but they have limited capability for modeling the 
physics of space links, orbits, spacecraft attitude, microwave 
interference sources, and other astronautical concerns. 

While some network simulations, such as the Network 
Simulator - ns-2, OMNeT++, OPNET, and QualNet, include 
the advanced propagation and antenna models necessary for 
space link modeling, they lack the breadth of tunable 
parameter-space found in astronautical physics simulators, 
which are directly suited to the space environment. 


Astronautical physics simulators, such as the Satellite Tool Kit 
(STK), have become very common in the aerospace industry 
for mission planning and communications, but their 
communications capability is limited to physical-layer link 
analysis. Therefore, a complete solution requires a 
combination of both tools. 

Cross-disciplinary systems engineering is another factor 
motivating our unified approach. Mission planning and other 
engineers make extensive use of astronautical physics 
simulators and have major investments in spacecraft models, 
planned trajectories, etc., whereas the engineers responsible for 
the design and definition of the network protocol stack and 
topology make their investments in test beds for emulation or 
modeling in network simulators. Thus, a major goal of a 
unified toolset is to allow the reuse of existing vetted models 
developed by subject-matter experts across both domains. 

There have been prior attempts at combining these tools 
[4], but they have undesirable limitations. One approach was 
to use the tools separately in a serial mode by first generating 
space link data from the physics simulator, then importing the 
data into the network simulator for use in end-to-end 
simulations [5]. This has several disadvantages. First, since 
the two tools are separate, the respective models and 
configuration parameters must be maintained separately despite 
their overlaps. Also, given that the duration of simulated 
scenarios can be lengthy, the generation of space link data 
before running the network simulation can require 
approximations, such as interpolation, which may lead to loss 
of precision. Other attempts at integrating the two approaches 
were focused on terrestrial wireless applications, and they were 
found to be insufficient for modeled the complexities of certain 
space links, such as bent-pipe relay satellites and deep space 
communications between multiple central bodies. Further, this 
type of simulation is not capable of modeling the effects of 
communication system performance on the dynamics of the 
space vehicle itself; for instance, dynamic loss or latency in the 
command path impacting timing of spacecraft operations. 

Alternative attempts for simulating communication systems 
were encountered within NASA. These attempts involved the 
chaining of piecemeal simulations developed separately by 
mission planning, RF, and network engineers in an effort to 
quantify end-to-end performance. This has also led to 
inconsistencies with overlapping models as well as the 


aforementioned loss of precision due to approximations, and 
the possibility for errors due to mismatched assumptions within 
the end-to-end system model. 

II. Approach 

Our approach, named GEMINI ([NASA] Glenn’s 
Environment for Modeling Integrated Network Infrastructure), 
is, to our knowledge, the first solution to successfully address 
all of these problems. GEMINI is a dynamic integration 
environment, meaning that the two specialized simulators run 
concurrently in parallel, and data is exchanged between them as 
necessary for space link events. Since GEMINI makes a clear 
partition leveraging the core capabilities of each of the two 
simulators, effectively replacing the network simulator’s 
physical layer propagation models when bits are radiated across 
space links, the models and configuration parameters can be 
consistently maintained without any duplication. 

For implementation we chose two COTS tools, the QualNet 
network simulator from Scalable Network Technologies and 
Satellite Tool Kit (STK) aeronautics and astronautics physics 
simulator from Analytical Graphics Inc. QualNet is the 
outgrowth of the DARPA funded GloMoSim project from the 
1990’s, and STK is widely used throughout the aerospace 
industry. 


data is translated into packets and frames. The data-link layer 
model informs the proper physical layer model when an 
outbound frame is ready to be radiated by the physical layer 
radio model. The simulator’s physical layer model is 
responsible for modeling the behavior of the radio, imposing 
link serialization and other transmission delays, and providing 
the simulator’s propagation model with the information 
required to calculate propagation delay and signal loss through 
the medium. 

Our integration of the QualNet network simulator and STK 
occurs at the physical layer of the simulated network stack. For 
each outbound frame that is provided to the simulator’s 
physical layer model for radiation across a space link, our 
custom model queries a specified mission scenario in STK. 
STK uses user-specified parameters and models to calculate the 
link budget for the space link at the corresponding time 
instance, and it responds to the query by providing both the bit- 
error rate (BER) and propagation delay for the link. Note that 
our QualNet/STK interface is only invoked by the network 
simulator for explicitly configured space links; for terrestrial 
and other links (e.g. WANs, backhaul links, cellular structures, 
etc.), QualNet uses its own capabilities for physical layer 
modeling. GEMINI considers the complete end-to-end 
network as a system with space links as components within that 
network. 


III. Design 


QualNet and STK are large, complex software tools, so a 
proper design of GEMINI depended on determining the 
specific integration points and analysis of the desired 
simulation data flow. 
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Fig. 1. GEMINI consists of both COTS and custom components 


As the network simulator models the flow of outbound 
simulated application traffic through the transport, network, 
and data-link layers of the network stack, a network simulator 
calculates the added overhead and timing delays as application 


Development of the GEMINI toolset was funded and supported by 
NASA’s Space Communication and Navigation (SCaN) Program. 


For detailed simulation of space links, in order to correctly 
integrate the physical layer models of both QualNet and STK, 
the parameters and settings entered in to both tools need to be 
consistent with the front-end flow between the space link 
transmitter and receiver. In our solution, the QualNet physical 
layer model is responsible for computing the transmit 
serialization delay of the entire frame based on the data rate 
and length, which includes forward error correction coding and 
frame synchronization overhead. 

IV. Use Case 

NASA’s Space Communications and Navigation (SCaN) 
Program is responsible for the development and operation of 
NASA’s space communication architecture. One of SCaN’s 
assets is the NASA Space Network (SN). The SN consists of 
space and ground segments that provide tracking and data relay 
for spacecraft, satellites, and expendable launch vehicles. The 
SN space segment consists of a number of Tracking and Data 
Relay Satellite (TDRS) systems in geostationary orbit (GEO), 
and the ground segment includes a number of ground terminals 
located at the White Sands Complex (WSC) near Las Cruces, 
New Mexico and a remote site in Guam. 

The SN will be responsible for providing communications 
for the Orion spacecraft, which has been developed as part of 
NASA’s Constellation (Cx) Program. Orion has been designed 
to initially transport astronauts to and from the International 
Space Station (ISS) in low-earth orbit (LEO); but later phases 
of the Cx program plan to use Orion to transport astronauts to 
the moon, Mars, and beyond. 

To demonstrate the practical use of GEMINI, we 
considered a mission scenario in which the Orion spacecraft is 
sending and receiving digital voice traffic with the Mission 
Control Center (MCC) at Johnson Space Center (JSC) in 





Houston, Texas for approximately one hour in LEO using the 
NASA Space Network. Like the Internet protocol suite, the Cx 
program’s network design uses layering to provide abstraction 
of protocols and services. Applications communicating 
between the spacecraft and the MCC use transport, network, 
and data link protocols to send and receive data. Prediction of 
end-to-end communications performance for such a mission is 
difficult using a network simulator alone, as the space link 
fidelity and signal propagation times vary throughout the 
scenario according to the orbital dynamics of the transmitter 
and receiver in the space environment. Likewise, solely using 
an astronautical physics or link budget calculation tool would 
be insufficient; data on the fidelity and propagation delay of the 
space link paints a relatively poor picture of end-to-end 
application performance across a network using the layered 
protocol paradigm. Additional performance disturbances due 
to factors such as adjustments in spacecraft attitude, antenna 
masking by structures, solar occlusion, and other performance 
impacts are not easily accounted for in a pure networking 
simulator. 

In our scenario, bidirectional full-duplex voice traffic using 
a fixed-rate codec is created by two constant bit rate (CBR) 
applications, one onboard Orion and the other at the MCC, 
each sending a 40 byte packet every 20 ms for the duration of 
the scenario. Data from the simulated digital voice codec is 
assembled into Internet Protocol (IP) packets, and then 
encapsulated and framed according to the CCSDS Advanced 
Orbiting Systems (AOS) space data link protocol [7] with the 
CCSDS Encapsulation Packet as a shim between IP and AOS. 
The AOS frames are radiated out of the Orion spacecraft 
transmitter to the TDRS F10 (also known as TDRS J) 
spacecraft over the Atlantic Ocean Region (AOR), which 
relays the data to a ground terminal at the White Sands 
Complex. In our scenario, the ground terminals process the 
signal back into frames and reconstruct the stream of IP 
packets, which are routed across gateways and routers to the 
MCC using the NASA Internal Services Network (NISN). 



Fig. 2. Initially, Orion communications are relayed through a White Sands 
Complex ground terminal via a TDRS over the Atlantic Ocean 

This data flow continues until an SN operational schedule 
change occurs just before the Orion spacecraft travels over the 
horizon and loses access to the Atlantic Ocean TDRS (at 
approximately 40 minutes). Afterwards, the Orion spacecraft 
radiates to a TDRS spacecraft over the Indian Ocean Region 
(IOR), which relays the data to a ground terminal in Guam. 



Fig. 3. After losing access to WSC, Orion communications are relayed 
through a Guam ground terminal via a TDRS over the Indian Ocean. 

During the course of the simulation, GEMINI records the 
end-to-end latency for each voice packet received on the return 
path (defined as the difference in time between the application- 
layer transmission and reception of each 40 byte voice packet 
across the end-to-end network flow). This end-to-end latency 
data is plotted against the 1-hour orbit time in Fig. 4. 

The end-to-end voice application latency was found to 
change over time, as shown in Fig. 4. The curvature visible in 
the plot is due to the gradual change in space-link propagation 
distance that occurs as Orion orbits the Earth. However, the 
dramatic 300-millisecond jump in end-to-end latency that 
occurs approximately 40 minutes into the scenario is attributed 
to the terrestrial links. The terrestrial network topology is such 
that changing the path of the network flow through the Guam 
ground terminal adds considerable latency, as the data must 
eventually be routed back to WSC and eventually to the MCC 
at Johnson Space Center (JSC) in Houston, TX. 



Fig. 4. End-to-end voice application latency is observed to change over 
time, with a substantial increase occuring after the SN schedule change. 

The thickness of the apparent line in the Fig. 4 scatter plot 
is due to the observed jitter in the voice application packet 
stream. Closer inspection of the data revealed that the voice 
application packet latency exhibited a saw-tooth pattern, as 
shown in Fig. 5. This is due to the insertion of “idle frames” 
into the AOS space data link, which are automatically inserted 
by the AOS protocol models that NASA developed for the 


simulator [6], Due to the limited data rate of the simulated 
voice streams, the link layer protocol onboard Orion 
occasionally finds that there are no network layer packets ready 
for transmission. As a result, an “idle frame” is sent to keep 
the synchronous space link active and maintain symbol 
synchronization at the demodulator; any outbound packets 
arriving into the link layer queue during transmission of this 
idle frame are required to wait for its completion before they 
can be transmitted. This contribution to end-to-end latency had 
not been captured in previous analytical evaluations of network 
performance, using spreadsheets and other techniques instead 
of full protocol simulation. 



Fig. 5. After losing access to WSC, Orion communications are relayed 
through a Guam ground terminal via a TDRS over the Indian Ocean. 


Conclusion 

In this paper we have demonstrated the benefits of a unified 
approach to the modeling and simulation of space 
communication networks and systems. We explained the 
design of our solution, GEMINI, which leverages the core 
competencies of two different tools in a dynamic integration of 
network simulation and astronautics physics simulation 
software. We have shown the application of GEMINI to 
predict the end-to-end latency of a digital voice application in 
an example human spaceflight mission scenario. The results 
obtained for our example use case illustrated the application- 
layer performance impact stemming from events and 
interactions across different communication domains, including 
physical mobility, network topology, and data-link layer 
protocol effects. 

Such an approach to modeling and simulation benefits the 
practitioners of systems engineering and architecting in several 


ways. First, we recognize that engineers involved in mission 
planning during early-phases of the systems engineering 
lifecycle operate with different tools, expertise, and domain 
knowledge than the engineers responsible for architecting end- 
to-end communications data flows, protocol stacks, and 
network topologies. Both groups have evolved separate 
toolsets, each tailored for requirements of practical application 
in their respective domains. It follows logically therefore new 
systems-of-systems architectures that bridge disparate domains 
will find themselves ill suited for analysis using existing tools. 
Our approach leverages partitions in the architecture - in this 
case, between the physical-layer functionality and the services 
provided by the data-link and higher layers - to interface the 
modeling and simulation tools used by both domains for an 
optimal solution. In addition, our use of existing tools allows 
us to reuse the models developed by subject-matter experts in 
both domains. This further benefits the systems engineering 
process by facilitating feedback of design trade-off and trade 
study analysis of the end-to-end communications architecture 
back into the design decisions and corresponding models of the 
mission plan, communications payload, and protocols. 
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